Telegram Group & Telegram Channel
Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:


macos-setup:
brew install overmind caddy


Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

Ссылки: Телеграм | Youtube | VK



tg-me.com/orgprog/317
Create:
Last Update:

Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:


macos-setup:
brew install overmind caddy


Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

Ссылки: Телеграм | Youtube | VK

BY Организованное программирование | Кирилл Мокевнин


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/orgprog/317

View MORE
Open in Telegram


Организованное программирование | Кирилл Мокевнин Telegram | DID YOU KNOW?

Date: |

How to Buy Bitcoin?

Most people buy Bitcoin via exchanges, such as Coinbase. Exchanges allow you to buy, sell and hold cryptocurrency, and setting up an account is similar to opening a brokerage account—you’ll need to verify your identity and provide some kind of funding source, such as a bank account or debit card. Major exchanges include Coinbase, Kraken, and Gemini. You can also buy Bitcoin at a broker like Robinhood. Regardless of where you buy your Bitcoin, you’ll need a digital wallet in which to store it. This might be what’s called a hot wallet or a cold wallet. A hot wallet (also called an online wallet) is stored by an exchange or a provider in the cloud. Providers of online wallets include Exodus, Electrum and Mycelium. A cold wallet (or mobile wallet) is an offline device used to store Bitcoin and is not connected to the Internet. Some mobile wallet options include Trezor and Ledger.

The messaging service and social-media platform owes creditors roughly $700 million by the end of April, according to people briefed on the company’s plans and loan documents viewed by The Wall Street Journal. At the same time, Telegram Group Inc. must cover rising equipment and bandwidth expenses because of its rapid growth, despite going years without attempting to generate revenue.

Организованное программирование | Кирилл Мокевнин from cn


Telegram Организованное программирование | Кирилл Мокевнин
FROM USA